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EXTENDED TRUSTED COMPUTING BASE 
BACKGROUND OF THE INVENTION 

Field of the Invention 

[0001] This invention generally relates to secure communications and in particular, to 
enhancing security policy relating to a trusted computing base of a computer system. 

Description of Related Art 

[0002] In many modem computing systems and networks, the reliability and security 
of information flow is of significant importance. To enforce the security policy of a 
computer system (system), a conventional hardware mechanism, such as a hardware- 
based Trusted Computing Base (TCB), is typically used. Such a hardware-based TCB is 
expected to enforce the system's access control policy and provide resistance to 
unauthorized changes to the system by utilizing various protection mechanisms. 
[0003] However, conventional hardware protection mechanisms do not provide 
adequate defense against deliberate attacks on the system, because defense against such 
attacks have to be based upon the presxmiption of hostility operators or programs on the 
system. In particular, these conventional hardware mechanisms are not sufficient to build 
a TCB that enforces mandatory access control policies in environments where the device 
cannot be physically secured and is vulnerable to attack by hostile operators. 
[0004] The operating system in conventional open platforms, such as personal 
computers (PCs), contain many changing components, such as device drivers and patches. 
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making it difficult to maintain the system in a continually trustworthy state. In high- 
security environments the TCB must protect sensitive information fi-om operators of the 
system. Such systems commonly use a closed platform, such as a set-top box, as opposed 
to an open platform, such as a PC, to reduce not only the number of components, but also 
to provide better security control over platform hardware and software. However, in 
comparison to PCs, closed systems are less flexible (fixed fimction) and often impose an 
additional cost to consumers. Furthermore, the security of closed function devices cannot 
be implemented into the open PC platforms, fiirther leaving the consumers without the 
economic benefit and delivery of richer applications and services. 
[0005] Conventional hardware-based TCBs are typically limited in speed and slow at 
secure processing, limited in storage capacity, support a very low level programming 
interface, have their resources shared by all the software running on the system including 
two or more virtual machines, provide difficulty with regard to migration of data used by 
a virtual machine fi-om one system to another system, and have readily unsuitable 
measurement facility for measuring application programs that are repeatedly terminated. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0006] The appended claims set forth the features of the present invention with 

particularity. The embodiments of the present invention, together with its advantages, 
may be best understood from the following detailed description taken in conjunction with 
the accompanying drawings of which: 

[0007] Figure 1 is a flow diagram illustrating an embodiment of a computer system; 
[0008] Figure 2 is a block diagram illustrating an embodiment of a Trusted 
Computing Base; 

[0009] Figure 3 is a block diagram illustrating an embodiment of a vertically 
extended Trusted Computing Base; 

[0010] Figure 4 is a flow diagram illustrating an embodiment of a process for 
vertically extending a Trusted Computing Base; 

[001 1] Figure 5 is a block diagram illustrating an embodiment of a horizontally 
extended Trusted Computing Base; and 

[0012] Figure 6 is a flow diagram illustrating an embodiment of a process for 
horizontally extending a Trusted Computing Base. 
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DETAILED DESCRIPTION 



[0013] A method and apparatus are described for extending a Trusted Computing 
Base (TCB) of a computer system or device (system). According to one embodiment, a 
hardware TCB of a system having trustworthy hardware components, including a Trusted 
Platform Module (TPM), may be extended into one or more layers of software TCB. The 
hardware TCB may be extended by adding one or more layers of software TCB to it. 
According to one embodiment, the properties associated with the hardware TCB may be 
transferred to the one or more layers of software TCB. The properties of the hardware 
TCB may include its trust and security properties. According to one embodiment, by 
having the trust and security properties of the hardware TCB projected onto the one or 
more layers of software TCB, the hardware TCB may be extended to overcome its 
hardware-related limitations. 

[0014] According to one embodiment, the hardware TCB may be extended vertically 
and/or horizontally to create a more flexible, secure, trustworthy, and feature-rich system 
TCB. To vertically extend the hardware TCB, according to one embodiment, multiple 
layers of software TCB having the trust and security properties of the hardware TCB may 
be built on the hardware TCB. To horizontally extend the hardware TCB, according to 
one embodiment, one layer of software TCB may be built on the hardware TCB and 
multiple virtual containers and virtual TPMs may be built on the software TCB. As with 
the vertically extended TCB, the layer of software TCB and the multiple virtual 
containers and virtual TPMs of the horizontally extended TCB may also have the trust 
and security properties of the hardware TCB. To ensure trustworthiness of the software 
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horizontally, extending the TCB by having the trust and security properties of the 
hardware TCB transferred to the software TCB. 

[0015] In the following description, numerous specific details such as logic 
implementations, opcodes, resource partitioning, resource sharing, and resource 
duplication implementations, types and interrelationships of system components, and 
logic partitioning/integration choices may be set forth in order to provide a more thorough 
understanding of various embodiments of the present invention. It will be appreciated, 
however, to one skilled in the art that the embodiments of the present invention may be 
practiced without such specific details, based on the disclosure provided. In other 
instances, control structures, gate level circuits and full software instruction sequences 
have not been shown in detail in order not to obscure the invention. Those of ordinary 
skill in the art, with the included descriptions, will be able to implement appropriate 
fimctionality without undue experimentation. 

[0016] Various embodiments of the present invention will be described below. The 
various embodiments may be performed by hardware components or may be embodied in 
machine-executable instructions, which may be used to cause a general-purpose or 
special-purpose processor or a machine or logic circuits programmed with the instructions 
to perform the various embodiments. Altematively, the various embodiments may be 
perfomied by a combination of hardware and software. 

[0017] Various embodiments of the present invention may be provided as a computer 
program product, which may include a machine-readable medium having stored thereon 
instructions, which may be used to program a computer (or other electronic devices) to 
perform a process according to various embcdiinents of the present invention. The 
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machine-readable medium may include, but is not limited to, floppy diskettes, optical 
disks, CD-ROMs, magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, 
magnetic or optical cards, flash memory, or another type of media/machine-readable 
medium suitable for storing electronic instructions. Moreover, various embodiments of 
the present invention may also be downloaded as a computer program product, wherein 
the program may be transferred from a remote computer to a requesting computer by way 
of data signals embodied in a carrier wave or other propagation medium via a 
communication link (e.g., a modem or network connection). 

[0018] Figure 1 is a block diagram illustrating an embodiment of a computer system. 
The computer system (system) includes one or more processors 102-106, including 
hyperthreaded or multi-threaded processors. A typical multi-threaded processor may 
include multiple threads or logical processors, and may be capable of processing multiple 
instruction sequences concurrently using its multiple threads. Processors 102-106 may 
also include one or more internal caches (not shown) and a bus controller 122 to direct 
interaction with the processor bus 112. 

[0019] Processor bus 112, also known as the host bus or the front side bus, may be 
used to couple the processors 102-106 with the system interface 114. Processor bus 112 
may include a control bus 132, an address bus 134, and a data bus 136. The control bus 
132, the address bus 134, and the data bus 136 may be multidrop bi-directional buses, 
e.g., connected to three or more bus agents, as opposed to a point-to-point bus, which 
may be connected only between two bus agents. 

[0020] System interface 1 14 (or chipset) may be connected to the processor bus 115 
to interface other components of the system J 00 with the processor bus 1 1 2. For 
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example, system interface 1 14 may includes a memory controller 1 18 for interfacing a 

main memory 116 with the processor bus 1 12. The main memory 1 16 typically includes 

one or more memory cards and a control circuit (not shown). System interface 114 may 

also include an input/output (I/O) controller 120 to interface one or more I/O bridges or 

I/O devices with the processor bus 1 12. For example, as illustrated, the I/O controller 

120 may interface an I/O bridge 124 with the processor bus 1 12. I/O bridge 124 may 

operate as a bus bridge to interface between the system interface 1 14 and an I/O bus 126. 

One or more I/O controllers and/or I/O devices may be connected with the I/O bus 126, 

such as I/O controller 128 and I/O device 130, as illustrated. I/O bus 126 may include a 

Peripheral Component Interconnect (PCI) bus or other type of I/O bus. 

[0021] System 100 may include a dynamic storage device, referred to as main 

memory 1 16, or a random access memory (RAM) or other coupled to the processor bus 

1 12 for storing information and instructions to be executed by the processors 102-106. 

Main memory 116 also may be used for storing temporary variables or other intermediate 

information during execution of instructions by the processors 102-106. System 100 may 

include a read only memory (ROM) and/or other static storage device coupled to the 

processor bus 1 12 for storing static information and instructions for processor 110. 

[0022] Main memory 1 16 or dynamic storage device may include magnetic disk or 

optical disc for storing information and instructions. I/O device 130 may include a 

display device (not shown), such as a cathode ray tube (CRT) or Liquid Crystal Display 

(LCD), for displaying information to an end user. For example, graphical and/or textual 

indications of installation status, time remaining in the trial period, and other information 

may he presented to the nrosnective nurchaser on the disnlav device. T/O device 130 mav 
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also include an input device (not shown), such as an alphanumeric input device, including 
alphanumeric and other keys for communicating infomiation and/or command selections 
to processor 110. Another type of user input device includes cursor control, such as a 
mouse, a trackball, or cursor direction keys for communicating direction information and 
command selections to the processors 102-106 and for controlling cursor movement on 
the display device. 

[0023] System 100 may also include a communication device (not shown), such as a 
modem, a network interface card, or other well-known interface devices, such as those 
used for coupling to Ethemet, token ring, or other types of physical attachment for 
purposes of providing a communication link to support a local or wide area network, for 
example. Stated differently, the system 100 may be coupled with a number of clients 
and/or servers via a conventional network infrastructure, such as a company's Intranet 
and/or the Intemet, for example. 

[0024] It is appreciated that a lesser or more equipped computer system than the 
example described above may be desirable for certain implementations. Therefore, the 
configuration of computer system 100 will vary from implementation to implementation 
depending upon numerous factors, such as price constraints, performance requirements, 
technological improvements, and/or other circumstances. 

[0025] It should be noted that, while the embodiments described herein may be 
performed under the control of a programmed processor, such as processors 102-106, in 
altemative embodiments, the embodiments may be fully or partially implemented by any 
programmable or hardcoded logic, such as Field Programmable Gate Arrays (FPGAs), 

TTL loeic. or Anolication Soecific Tnteerated Circuits ^ A STCsV AHHitionallv th^ 

^ . ^ ^ ^ ^ \---/- ./ » — 
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embodiments of the present invention may be perfomied by any combination of 
programmed general-purpose computer components and/or custom hardware 
components. Therefore, nothing disclosed herein should be construed as limiting the 
various embodiments of the present invention to a particular embodiment wherein the 
recited embodiments may be performed by a specific combination of hardware 
components. 

[0026] Figure 2 is a block diagram illustrating an embodiment of a hardware Trusted 
Computing Base. As illustrated, computer system or device (system) ICQ may include a 
hardware Trusted Computing Base (TCB) 206 based on a hardware device, such as a 
Trusted Platform Module (TPM) 204, a processor 102 having security extensions to 
provide a tamper-resistant facility for software measurement and address space isolation, 
and a system interface or chipset, such as the security-enhanced chipset, 1 14 to provide 
special security capabilities including the ability to selectively protect main memory 116 
firom, for example. Direct Memory Access (DMA)-based input/output (I/O). The system 
100 may be referred to as the TCB-based system 100. 

[0027] According to one embodiment, the TCB 206 may be manufactured by a 
system or device manufacturer so that the TCB 206 may be equipped to perform, for 
example, fimctions necessary for supporting various protocols and delivering the baseline 
hardware security capabilities, as described herein. According to one embodiment, the 
TCB-based system 100 may include various specialized security mechanisms including 
one or more of the following: the ability to measure software in a tamper-resistant 
manner, a secure storage for confidential information, a unique machine identity, and the 
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ability to securely report the measured integrity of software on the system 100 (e.g., by a 
process known as attestation) to a remote system. 

[0028] According to one embodiment, the processor 102 may be used to measure the 
booted software in a tamper-resistant manner, and the TPM 204 may be utilized as a 
secure co-processor to provide tamper-resistant secure storage for confidential 
inforaiation, tamper-resistant storage for measured values, and tamper-resistant 
cryptographic algorithms to support attestation protocols. For example, the tamper- 
resistant processor 102 may be used to measure software that may be loaded on the 
system 100. According to one embodiment, the measured value may be cryptographic 
hash of the software image and may represent the integrity of the measured software. 
According to one embodiment, the measured value may be subsequently signed by a 
tamper-resistant co-processor (e.g., the TPM 204) using a key that may be contained and 
hidden in the TCB 206 and more particularly, for example, in the TPM 204. According 
to one embodiment, the process of attestation may be used for having the signed value 
reported to a remote system via, for example, a cryptographic protocol. The remote 
system may ascertain the trustworthiness of the measured software and may make a trust 
decision based on the trustworthiness of information reported by the hardware TCB 206 
of the measured system 100. 

[0029] According to one embodiment, the TPM 204 may hold previously measured 
information about the software and hardware environment of the system 100. Each of the 
TPMs, such as the TPM 204, may have a unique endorsement key (EK) to be used to 
establish an identity for the system 100. The TPM 204 may have a cryptographic 

execution engine to support an attestation protocol using the measured values and the 
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system identity. Furthermore, the TPM 204 may have a secure storage facility in which 
applications may store keys and other secrets. These secrets may be released to the 
applications if, for example, they present the right credentials. The TPM 204 may not 
raise the assurance level of the system 100 as a whole on its own, because it may not 
directly measure software; however, that task may be performed by the processor 102 and 
the result may be stored in the TPM 204. According to one embodiment, the 
trustworthiness of the system 100 may be anchored in the hardware TCB 206. 
[0030] According to one embodiment, the hardware TCB 206 may be extended 
vertically and/or horizontally with layers of software to create a more flexible and feature- 
rich system TCB. According to one embodiment, to ensure the trustworthiness of the 
layers of software TCB, the hardware TCB 206 may remain the root of trust of the overall 
system TCB. Stated differently, the trust and security properties of the hardware TCB 
206 may be transmitted onto the software TCB to maintain the trustworthiness of the 
entire TCB including both the hardware TCB 206 and the software TCB. 
[0031] Figure 3 is a block diagram illustrating an embodiment of a vertically 
extended Trusted Computing Base. According to one embodiment, the Level one 
hardware Trusted Computing Base (LI TCB) 206 may be used as a tamper-resistant 
trustworthy measurement and attestation agent to establish the identity and integrity of 
platform software (e.g., via a checksum or hash) in order to, for example, enable a remote 
entity, such as a computer system (system), to assess its trustworthiness. Such capability 
may be important in environments that depend on system software monitors that enforce 
mandatory access controls (MAC). 
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[0032] According to one embodiment, the hardware LI TCB 206 may be used to build 
an extended TCB 300 by adding one or more layers of software. For example, according 
to one embodiment, a layer of software, such as Level two software TCB (L2 TCB) 304, 
may be added to or built upon the LI TCB 206. The L2 TCB 304 may include a trusted 
kernel, while the LI TCB 206 may include various hardware components, such as a 
Trusted Platform Module (TPM) 204, as discussed with reference to Figure 2. According 
to one embodiment, the trust and security properties of the LI TCB 206 may be 
transferred or projected onto the L2 TCB 304 via, for example, a Level one TCB interface 
(LI TCB interface) 310. According to one embodiment, the LI TCB interface 310 may 
expose certain security services and properties that may be used to create an appropriate 
execution environment for the L2 TCB 304. According to one embodiment, these 
services and properties may include one or more of the following: hardware-based 
software measurement facility, hardware-based tamper-resistant secure storage, Direct 
Memory Access (DMA) protection from input/output (I/O) devices, address-space 
isolation, and attestation of measurements to remote machines or systems via a root key 
contained in the hardware. 

[0033] According to one embodiment, the LI TCB interface 310 may include a low- 
level hardware TCB interface with certain inherent, necessary, or desired limitations. 
According to one embodiment, the L2 TCB 304 may be constructed using the low- level 
LI TCB interface 310. For example, by utilizing the LI TCB services via the LI TCB 
interface 310, the L2 TCB 304 may have a secured software kemel, and the L2 TCB 304 
may be used to implement one or more of the following: a tamper-resistant measurement 
facility in software, a software-based tamper-resistant secured storage facility, and a 
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software-based attestation facility. As opposed to code in the LI hardware TCB, much of 
which may be executed using a slow co-processor (e.g. the TPM) having a relatively 
small storage capacity, the code in the L2 TCB 304 may be executed on the main 
processor, such as the processor 102, while utilizing the main memory 1 16 for its 
operations. 

[0034] According to one embodiment, the L2 TCB 304 having a secure kemel may 
measure other software, such as device drivers and loadable modules, running on the 
system 100, and may store these measurements within its own protected area (e.g., in the 
Random Access Memory). Furthermore, according to one embodiment, a private key 
stored in the L2 TCB 304 may also perform attestations of software that the L2 TCB 304 
may be used to measure. 

[0035] According to one embodiment, the trustworthiness of the L2 TCB 304 may 
depend on the trust of the underlying LI TCB 206 by, for example, having the trust and 
security properties of the LI TCB 206 inductively transitively projected from the 
hardware-based LI TCB 206 to the software-based L2 TCB 304. For example, 
attestations made by the L2 TCB 304 may include an attestation of the L2 TCB 304 made 
by the LI TCB 206 by having the LI TCB 206 sign one or more public keys of the L2 
TCB 304 that may correspond to the private keys used by the L2 TCB 304 for attestation. 
According to one embodiment, this attestation chain may not be limited to one software- 
based TCB, such as the L2 TCB 304, but may also continue with additional software- 
based TCB layers. Having the attestations rooted in and measured by the hardware-based 
LI TCB 206 may help provide and maintain a high security assurance and trustworthiness 
for software including various software-based TCB layers, such as the L2 TCB 304. 
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[0036] According to one embodiment, to further vertically extend the hardware-based 
LI TCB 206, additional layers of software, such as Level three software TCB (L3 TCB) 
306, may be added to or built upon, for example, the L2 TCB 304. Similarly, another 
layer of software, such as Level four software TCB (L4 TCB) 308 may be added to or 
built upon, for example, the L3 TCB 306. According to one embodiment, the L3 TCB 
306 may include trusted services (e.g., network services, file system services, and 
provisioning services) and the L4 TCB 308 may include trusted applications (e.g., login, 
biometric pattem matching, and signal processing). As with the L2 TCB 304, the trust 
and security properties of the LI TCB 206 may be inductively transferred onto the 
multiple software layers of TCB (e.g., L3 TCB 306 and L4 TCB 308) via multiple TCB 
interfaces, such as Level two TCB interface (L2 TCB interface) 312 and Level three TCB 
interface (L3 TCB interface) 314, as indicated by the transitive trust arrows 324-328. 
[00371 According to one embodiment, properties, such as qualities and capabilities, 
of each of the TCB interfaces at various layers (e.g., LI, L2, and L3 TCB interfaces 310- 
314) may be tailored to suit the requirements of software at that layer (e.g., L2, L3, and 
L4 TCB 304-308). For example, at the L2 TCB interface 312, the data types may be 
richer and the storage size may be much larger than at the LI TCB interface 310, because 
the L2 TCB interface 3 12 exposed by the L2 TCB 304 may be at a much higher and more 
intuitive level of abstraction and may also expose a significantly different programming 
model than the LI TCB interface 310 exposed by the LI TCB 206. 
[0038] According to one embodiment, the TCB-like trust and security properties may 
include a secured storage facility, one or more measurement agents, an attestation facility, 
and a tamper-resistant execution environment for soft\vHre created recursively using the 
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software-based L2-L4 TCBs 304-308 and terminating at the hardware-based LI TCB 
206. According to one embodiment, the LI TCB 206 having the hardware TPM 204 may 
provide a hardware-based trustworthy foundation for the recursive chain of L2-L4 TCBs 
304-308 via a measurement facility rooted in the trustworthy hardware-based LI TCB 
206. According to one embodiment, the software-based TCBs, such as the L2-L4 TCBs 
304-308, may rely upon the hardware protection architecture of the LI TCB 206 in 
combination with secured operating system (OS) design (e.g., MAC-based security or 
carefiil control of all machine resources via memory & I/O isolation) to provide tamper- 
resistance for themselves. 

[0039] According to one embodiment, the TCB-like trust and security properties may 
make circumventing the vertically extended TCB 300 infeasible by, for example, 
continually mediating, restricting, and grating all accesses, based on an access control 
policy. Furthermore, according to one embodiment, the TCB 300 may be self-protected 
and resistant to unauthorized change or access, and yet the TCB 300 may be simple 
enough to have an open design to be analyzed for correctness, as necessitated. 
[0040] According to one embodiment, a software-based TCB, such as the L2 TCB 
304, may include a trusted reference monitor (monitor) having and exhibiting the trust 
and security properties of the TCB 300. The monitor may be part of an operating system 
or a virtual machine monitor to enforce the authorized access relationships between 
various components of a system, such as the system 100. According to one embodiment, 
the monitor may establish its trustworthiness by demonstrating the ability to enforce 
access control policy with regard to volatile and persistent data and thus, performing as an 
overall guard of the systeiii 100. This trustworthiness may be represented to a remote 
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system via an attestation protocol that demonstrates the integrity of the monitor using the 
hardware LI TCB 206 as being the root of trust for the signature in the attestation 
protocol. Since the monitor may be certified by a trusted authority, it may also provide 
necessary security assurance, which typically refers to the degree of confidence in the 
ability of a system to meet its security objectives. 

[0041] According to one embodiment, the LI TCB 206 may be provisioned with 
platform keys that reside in the hardware TPM 204 exposing its services to the L2 TCB 
304 via the LI TCB interface 310. The LI TCB interface 310 may also correspond to the 
low-level hardware interfaces exposed by the TPM 204 and other related hardware of the 
system 100. According to one embodiment, the LI TCB 206 may contain a hardware- 
based measurement agent that may be the root of trust for all integrity measurement (e.g. 
a processor microcode that measures a module code). Thus, the lowest tmsted hardware 
foundation, such as the LI TCB 206, may be referred to as the root of trust of the entire 
vertically extended TCB, such as the TCB 300. 

[0042] According to one embodiment, the LI TCB 206 may be directly or indirectly 
coupled with a hardware secure storage facility, such as the hardware secure storage 316. 
According to one embodiment, the L2 TCB 304 may internally implement a logical or 
virtual secure storage facility 3 1 8 by using encrypted disk files. The encryption keys for 
the virtual secure storage facility 318 may not leave the L2 TCB 304 except to be 
encrypted within the LI TCB 206. According to one embodiment, as with the LI TCB 
206, the L2 TCB 304 may contain a measurement agent and its own equivalent of values 
that it may use for integrity measurement of the L3 TCB 306. Furthermore, as with the 
LI TCB 206, the L2 TCB 304 may be provisioned with the secrets and certificates it 
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needs to perform its function. According to one embodiment, the L2 TCB 304 may 
expose its services to the L3 TCB 306 via the L2 TCB interface 312. According to one 
embodiment, like L2 TCB 304, other software TCB layers, such as the L3 TCB 306 and 
the L3 TCB 308, may also internally implement logical or virtual secure storage facilities, 
such as the virtual secure storages 320 and 322, using encrypted disk files, and may 
expose their trust and services to other software TCB layers up to the N^^ layer of 
software TCB via transitive trust by induction, as described herein. 
[0043] According to one embodiment, the TCB 300 may enable a peer-to-peer 
interaction between two machines or systems of each of the customized software TCB 
layers, such as the L2-L4 TCBs 304-308, at their own level without each being 
encumbered by the implementation details of the TCBs below it. According to one 
embodiment, the remote entity or system validating attestations may need to know about 
the security assurance of the various TCBs, such as 302-308, in the chain. 
[0044] According to one embodiment, using the vertically extended TCB 300, the 
integrity of every software module may be appropriately measured. While the 
trustworthiness of all software is eventually rooted in a hardware measurement of the 
base hardware, such as the LI TCB 206, for the software at other levels, such as the L2- 
L4 TCB 304-308, the measiwement, and its timing and content, may not be limited or 
dictated by the capabilities of the hardware LI TCB 206. 

[0045] Furthermore, according to one embodiment, the vertically extended TCB 300 
may be immune from a total TCB compromise or violation. For example, if the TCB 300 
at a particular level (e.g., L3 TCB 306) is compromised, all higher-level TCBs (e.g., L4 
TCB 308) may also be considered ccmprcmiscd because they depended on their !ov/er- 
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level TCBs which include the compromised TCB (e.g., L3 TCB 306). However, the 
lower-level TCBs (e.g., L2 TCB 304) below the compromised L3 TCB 306 may not be 
violated or compromised and still be considered secured. Thus, in case of a TCB 
compromise, the TCBs at the level of the compromised TCB (e.g., L3 TCB 306) and 
above (e.g., L4 TCB 308) may need to be re-established, and the TCBs lower than the 
compromised TCB may remain uncompromised, active, and secured. 
[0046] Figure 4 is a flow diagram illustrating an embodiment of a process for 
vertically extending a Trusted Computing Base. First, according to one embodiment, a 
Trusted Computing Base (TCB) for a computer system or device (system) may be 
generated using a trusted hardware device or platform, such as a Trusted Platform 
Module (TPM), in combination with other hardware components (e.g., hardware-based 
measurement of booted software and Direct Memory Access (DMA) protection from 
input/output (I/O) devices) at processing block 402. The TCB may be referred to as the 
Level one hardware TCB (LI TCB). At processing block 404, to vertically extend the LI 
TCB, a software TCB layer may be added to or built on top of the LI TCB. The software 
TCB layer may be referred to as the Level two software TCB (L2 TCB), and may include 
a trusted kemel. According to one embodiment, the trust and security properties of the 
LI TCB may be transferred (e.g., using an induction process) to the L2 TCB and via a 
Level one TCB interface (LI TCB interface) at processing block 406. 
[0047] According to one embodiment, a Level three software TCB (L3 TCB) may be 
added to or built on top of the L2 TCB providing another layer of software TCB at 
processing block 408. The L3 TCB may include trusted services, such as network 
services, flic system ser/iees, and provisioning ser/ices. At processing block ^10, the 
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trust and security properties of the LI TCB may be transferred to the L3 TCB using the 
L2 TCB and via a Level two TCB interface (L2 TCB interface). According to one 
embodiment, a Level four software TCB (L4 TCB) may be added to or built on top of the 
L3 TCB to provide another layer of software TCB and fiirther vertically extending the LI 
TCB at processing block 412. The L4 TCB may include trusted applications, such as 
login, biometric pattern matching, and signal processing. At processing block 414, the 
trust and security properties of the LI TCB may be transferred to the L4 TCB using the 
L3 TCB and via a Level three TCB interface (L3 TCB interface). 
[0048] According to one embodiment, at decision block 416, determination with 
regard to whether another software TCB layer is needed may be made. A system may or 
may not need another software TCB depending on various security and administrative 
factors, such as organizational goals, predetermined security criteria, and system 
vulnerabihty. If no more software TCB layers are needed, the process of vertically 
extending the TCB may end at processing block 418. However, if more software layers 
of TCB are necessitated, one or more layers of software TCB up to the N^^ level (Level N 
TCB) may be added to, for example, the Level N-1 TCB at processing block 420. 
According to one embodiment, the trust and security properties of the LI TCB may be 
transferred to the Level N TCB using the Level N-1 TCB and via the Level N-1 TCB 
interface. 

[0049] Figure 5 is a block diagram illustrating an embodiment of a horizontally 
extended Trusted Computing Base. According to one embodiment, as described with 
referenced to Figures 2 and 3, a Trusted Platform Module (TPM) 204 and other 
Lrusiworuiy iiai'uwaic comporiciits (e.g., liardware-bascd measurement of booted soft'rvare 
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and Direct Memory Access (DMA) protection from input/output (I/O) devices) may be 
used to form a trustworthy hardware computing base, such as Level one tamper-resistant 
hardware Trusted Computing Base (LI TCB) 206. According to one embodiment, the LI 
TCB 206 may be extended horizontally into a horizontally extended TCB 500. 
[0050] According to one embodiment, as described with reference to Figure 3, a 
software layer, such as Level two software TCB (L2 TCB) 502, may be added to or built 
upon the LI TCB 206. According to one embodiment, the TCB 500 may include one or 
more virtual containers, such as virtual containers 508-5 10, populated with a variety of 
information depending on the functionality of the L2 TCB 502. For example, if the L2 
TCB 502 includes a trusted kernel, each of the two virtual containers 508-510 may 
contain an application. If, for example, the L2 TCB 502 includes a virtual machine 
monitor (VMM), each of the virtual containers 508-510 may contain a virtual machine 
(VM). According to one embodiment, each of the virtual containers 508-510 may contain 
one or more of the following: trusted kernel, trusted services (e.g., network services, file 
system services, and provisioning services), and trusted applications (e.g., login, 
biometric pattem matching, and signal processing). 

[0051] According to one embodiment, the L2 TCB 502 including, for example, a 
VMM may, in turn, host several virtual containers 508-510 containing VMs, and the L2 
TCB 502 may implement a number of virtual software TPMs (virtual TPMs), such as the 
virtual TPMs 504-506, in software, and assign each of the virtual TPMs 504-506 to its 
corresponding virtual container 508-5 10 for its exclusive use. Each of the virtual TPMs 
504-506 may implement virtual secure storage in software via encryption. According to 
one embodiment, the encryption key of each of the virtual TPMs 504-506 may iiself be 
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encrypted and stored within the hardware-based LI TCB 206, keeping the LI TCB 206 as 
the root of trust for the horizontally extended TCB 500. For example, having built the L2 
TCB 502 using the trust and security properties of the LI TCB 206, the virtual TPMs 
504-506, implemented using the L2 TCB 502, may also have the trust and security 
properties similar to that of the LI TCB 206. 

[0052] As discussed with referenced to Figure 3, according to one embodiment, the 
trust and security properties of the hardware-based LI TCB 206 may be transferred to the 
virtual containers 508-510 using, for example, virtual TCB interfaces, such as Level one 
TCB interface (LI TCB interface) 512 and the Level two TCB interface (L2 TCB 
interface) 514. According to one embodiment, the LI TCB interface 512 and the L2 TCB 
interface 514 may be exposed by the LI TCB 206 and the L2 TCB 502, respectively. The 
transferring of the trust and security properties of the LI TCB 206 to the L2 TCB 502 and 
the virtual containers 508-510 is illustrated by a number of arrows labeled as transitive 
trust 516-520. 

[0053] According to one embodiment, the software-based L2 TCB 502 may not 
merely virtualize the functionality of the hardware-based LI TCB 206, but also perform 
the virtualization such that the trust and security properties of the hardware-based LI 
TCB 206 may be mimicked or imitated in software of the L2 TCB 502. According to one 
embodiment, the mimicking of the trust and security properties of the LI TCB 206 may 
be necessary for a software TCB layer, such as the L2 TCB 502, to represent its own 
trustworthiness to a third party, such as a remote entity or system, with a need to know. 
According to one embodiment, the virtual TPMs 504-506, having the trust and security 
properties of me hardware TFM 204 of the LI TCB 206, may facilitate a secured and 
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measured launch of software in the virtual containers 508-5 10 to that the launched 
software within the virtual containers 508-510 may fail to recognize that the virtual 
containers 508-510 are not running directly in contact with the LI TCB 206. 
[0054] According to one embodiment, by having the L2 TCB 502 with the trust and 
security properties of LI TCB 206, the implementation of virtual TPMs 504-506 in 
software and assignation of each of the virtual TPMs 504-506 to a particular virtual 
container 508-510 may help the LI TCB 206 support multiple parallel trustworthy 
software stacks in each of the virtual containers 508-510 from different vendors. 
[0055] Furthermore, according to one embodiment, virtual containers 508-5 10 may 
be deleted or migrated and their corresponding virtual TPMs 504-506 may also be deleted 
or migrated, as necessitated. For example, a virtual container (e.g., virtual container 508) 
may hold a UNIX process that has its own corresponding virtual TPM (e.g., virtual TPM 
504). When this UNIX process is migrated to a different machine or system, the TPM 
data in the corresponding virtual TPM 504 may also be migrated to the different machine 
along with it. Multiple additional virtual containers and virtual TPMs may be added to 
fiuther expand the horizontally extended TCB 500 up to the N^^ virtual container and the 
N^^ TPM. If no more virtual containers or virtual TPMs are to be added, the process of 
horizontally extending the LI TCB 206 may be terminated. 
[0056] Figure 6 is a flow diagram illustrating an embodiment of a process for 
horizontally extending a Trusted Computing Base. First, according to one embodiment, a 
Trusted Computing Base (TCB) for a computer system or device (system) may be 
generated using a trusted hardware device or platform, such as a Trusted Platform 
Module (TPM), and other hardwiire cuiiipuxiciiis (e.g., haidware-baseu measuieruent of 
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booted software and Direct Memory Access (DMA) protection from input/output (I/O) 
devices) at processing block 602. The TCB may be referred to as the Level one hardware 
TCB (LI TCB). At processing block 404, to extend the LI TCB, a software TCB may be 
added to or built on top of the LI TCB. The software TCB may be referred to as the 
Level two software TCB (L2 TCB) and may include, for example, a trusted kemel. 
According to one embodiment, the trust and security properties of the LI TCB may be 
transferred or transitioned to the L2 TCB using, for example, a Level one TCB interface 
(LI TCB interface) at processing block 606. 

[00571 According to one embodiment, to horizontally extend the LI TCB, a virtual 
software TPM (virtual TPM) having the trust and security properties of the hardware- 
based TPM of the LI TCB may be added to the L2 TCB at processing block 608. At 
processing block 610, the first virtual TPM in the L2 TCB may be assigned to the first 
virtual container. The trust and security properties of the hardware LI TCB may be 
transferred to the first virtual container using the L2 TCB and a Level two TCB interface 
(L2 TCB interface) at processing block 612. 

[0058] According to one embodiment, to fiirther horizontally extend the LI TCB, a 
second virtual TPM having the trust and security of properties of the hardware-based 
TPM of the LI TCB may be added to the L2 TCB at processing block 614. At processing 
block 616, a second virtual container corresponding to the second virtual TPM may be 
assigned to the L2 TCB. The trust and security properties of the hardware LI TCB may 
be transferred (e.g., via the induction process) to the second virtual container using the L2 
TCB and via the L2 TCB interface at processing block 618. 
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[0059] According to one embodiment, at decision block 620, deteraiination of 
whether additional virtual TPMs and/or corresponding virtual containers are needed may 
be made. A system may or may not need another virtual TPM and/or virtual container 
depending on various security and administrative factors, such as organizational goals, 
predetermined security criteria, and system vuhierability. If no more virtual TPMs or 
virtual containers are needed, the process of horizontally extending the TCB may end at 
processing block 622. However, if more virtual TPMs and/or virtual containers are 
necessitated, one or more virtual TPMs (e.g., virtual TPM N) and the corresponding 
virtual containers (e.g., virtual container N) may be added at processing block 624. 
According to one embodiment, the trust and security properties of the LI TCB may be 
transferred to the virtual TPM N using the L2 TCB and to the virtual container N using 
the L2 TCB and via the L2 TCB interface. 

[0060] While certain exemplary embodiments have been described and shown in the 
accompanying drawings, it is to be understood that such embodiments are merely 
illustrative of and not restrictive, and that the embodiments of the present invention are 
not to be limited to specific constructions and arrangements shown and described, since 
various other modifications may occur to those ordinarily skilled in the art upon studying 
this disclosure. 
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